Modern operating systems drive many of today's technology-based innovations by offering a platform for both hardware and software development while serving many diverse needs. These systems have evolved from more simplistic file management systems to more complex workstations that provide high-end performance at reasonable cost. Such systems often include multi-processing architectures, high-speed memory, advanced peripheral devices, a variety of system libraries and components to aid software development, and intricate/interleaved bus architectures, for example. At the heart of these systems, include processor support functionality such as advanced memory controllers and interrupt controllers that route a plurality of system interrupts to one or more intelligent devices or components. As systems become more complex, such as in a multi-processing system, management of interrupt resources (e.g. managing, processing, and allocating interrupt requests (IRQ)), has become ever more challenging.
In one example of a modern processing architecture, within a Plug and Play (PnP) subsystem employed in many computer systems, there is a concept of an “arbiter.” This is generally a software plug-in, supplied by a Plug and Play Manager or a device driver, for example, which arbitrates resources for other devices. Resources are an aspect of Plug and Play that can be expressed as a range. Memory address space on a PCI bus, for example, can be expressed as a starting address and an ending address. In this example, a PCI driver provides an arbiter for memory address space on a PCI bus.
Interrupt resources (also known as IRQs) are arbitrated much like any other resource. Respective IRQs can be expressed as a range, usually as IRQ 1 through IRQ 10, for example. If a device needs an IRQ, it may request resources via PnP messages, referred to as IRPs. Thus, an associated arbiter decides which IRQ is appropriate, and assigns a specific resource for the task at hand. This typically operates in existing PnP subsystems, by assigning an IRQ first, and then determining other data surrounding the IRQ, such as an affinity mask, which is a set of processors that can be targeted by the interrupt. This attachment of extra information associated with the IRQ generally occurs in a “resource translation” phase of resource assignment.
Previous methods, which involved arbitrating an IRQ and then selecting associated data after the fact, was generally sufficient for earlier operating systems, but it was not always flexible enough for emerging I/O bus technologies. It also made it difficult for administrators to intelligently determine a set of processors that would be targeted by a specific device's interrupts. Also, the infrastructure in Plug and Play subsystems—as well as others, operates with device resources in a one-dimensional manner, wherein respective resources are treated separately.
Resources can be, but are not limited to, the following types: I/O Ports; Memory locations; IRQs; DMA channels; and Bus Numbers. While a device may need resources in multiple categories, respective resource requests are generally taken separately, and represented as a one-dimensional range. A device (A) may, for example, request a resource set that appears like the following:                Any 16 I/O ports;        Any 256 bytes of memory address space;        One IRQ between 0 and 255; and        Four bus numbers.        
Or, a different device (B) may request:                I/O Port 0×220 through I/O port 0×221; and        IRQ 3 or IRQ 5.        
The PnP subsystem generally breaks down the problem into separate resource requests and passes them onto the arbiter. The arbiter for I/O ports, would then receive a request such as:                Device A—any 16 I/O ports;        Device B—I/O Port 0x220 through I/O port 0x221.The arbiter would then attempt to satisfy these requests. This one-dimensional view of resources is typically suitable for most resource types except IRQs. In order for a device to interrupt the processor, the device has to be connected to an input on an interrupt controller and it also has to insert an interrupt service routine (ISR) into an associated interrupt descriptor table (IDT). Thus, the choices involved in interrupt assignment are inherently two-dimensional.        
This two-dimensionality was not completely understood when PnP subsystems in various operating systems were originally designed. In one case, an 8259 interrupt controller has a relatively fixed IRQ-to-IDT mapping. Generally, operating systems program a base IDT entry, 0×70 for example, for IRQ 0. Thus, IRQ 9 will utilize IDT entry 0×79. Furthermore, since the IDT exists separately for respective processors in the machine, if the machine has more than one processor, the IDT entry component of the interrupt assignment is itself multi-dimensional. Complicating the matter even more, new I/O bus technologies, summed up in the term Message-Signaled Interrupt, allow a device to trigger more than one IRQ, or sometimes cause a processor to jump through an IDT entry to an ISR without involving an IRQ.
These aspects, taken together, indicate that traditional approaches, which involve selecting an IRQ in the arbitration process and then selecting IDT entries at a later time, may cause operating system problems. One factor is that there may not be enough IDT entries available, or the ones that are available may be associated with processors that are not optimal. Thus, the arbiter may answer the PnP manager indicating that there is an IRQ that is applicable for a device, but after assignment is achieved, the device still would not be able to deliver an interrupt.